Het is altijd bevredigend om krachtige nieuwe manieren te delen om problemen op te lossen, vooral wanneer de oplossing al een tijdje "in het volle zicht verborgen" is. Deze keer laat ik zien hoe de combinatie van ArcGIS Enterprise branch versioning en cloud native data sharing niet alleen snelle toegang tot data biedt aan mensen zonder portaltoegang, maar ook de mogelijkheid om de geraadpleegde data te laten terugreizen in de tijd naar toen het jonger was. Zoals deze percelen, zie een eerder onverdeeld perceel en nu zijn drie onderverdelingen.<\/P>
Parcel subdivision<\/span><\/span>Parcel subdivision<\/SPAN><\/SPAN><\/SPAN><\/P>Stel je een dataset voor met miljoenen features die dagelijks intensief wordt onderhouden, zoals branch versioning is ontworpen om aan te kunnen, je klanten kunnen elk deel of de volledige standaardversie op elk moment in de tijd benaderen. Voor altijd. Zonder extra belasting op je Enterprise portal.<\/P>Hoe ben ik daar gekomen? Ik merkte simpelweg dat het insert-only transactiemodel van branch versioning geschikt is voor het incrementeel creëren van GeoParquet-bestanden in cloudopslag die gezamenlijk de datastatus in de tijd behouden en ruimtelijk en temporeel kunnen worden bevraagd om lokale data op aanvraag te maken voor jouw interessegebied en tijd.<\/P>Het is echter een zeer geavanceerde query! Het goede nieuws is dat je het niet zelf hoeft uit te zoeken, de blogdownload bevat een notebook met voorbeelden voor mijn perceelonderwerp, plug gewoon die van jou in.<\/P>Ik hoefde de querybenadering niet zelf uit te vinden, Esri publiceert workshopmaterialen over dit onderwerp. Bijvoorbeeld, als je rond minuut 18 in deze presentatie kijkt, zie je hoe zo'n query eruitziet.<\/P>Spoiler<\/a>de archive class aan de kaart toevoegt, zijn ze beschikbaar:<\/P>
Archive class added to the map<\/span><\/span>Archive class added to the map<\/SPAN><\/SPAN><\/SPAN><\/P>Een paar dingen om op te merken in het veldenoverzicht: ObjectID wordt gedegradeerd tot een gewone lange integer (waarden zijn niet meer uniek) en verschillende velden met de naam GDB_* worden toegevoegd. Ze maken het mogelijk om data op een bepaald moment in de tijd te bekijken, wat precies is hoe branch versioning werkt - de laatste status van een feature wint, wat ook een verwijderde status kan zijn, maar de datahistorie gaat niet verloren (tenzij je die verwijdert), waardoor tijdreizen mogelijk wordt.<\/P>De archive class is ook handig om te ontdekken welke bewerkingsmomenten er in je data zitten.<\/P>Met de archive class die zichtbaarheid biedt op alle velden was de deel- en onderhoudswerkflow mogelijk. Die verloopt als volgt:<\/P>Maak een initiëel parquet-bestand met alle rijen van de archive class waar GDB_BRANCH_ID = 0<\/LI>Maak volgens een zinvolle planning delta parquet-bestanden voor nieuwe standaard branch rijstatussenDeze hebben een GDB_FROM_DATE later dan het maximum in alle bestaande parquet-bestanden<\/LI>Ze hebben ook GDB_BRANCH_ID = 0<\/LI><\/UL><\/LI>Onderhoud alle parquet-bestanden in je favoriete S3-compatibele object store op een glob-pad<\/LI>Geef je dataklanten een notebook of scripttool die ze kunnen gebruiken om data te extraherenDe meegeleverde notebook vereist DuckDB versie 1.0.0 in de Python-omgeving<\/LI><\/UL><\/LI><\/UL>Ik promoot dit nu als cloud native data distributie, maar op het moment van schrijven ben ik nog mijn AWS-account aan het instellen dus gebruikt de bijgevoegde notebook een lokaal bestandspad; ik zal dat bijwerken zodra ik een publieke S3-URL heb. In de tussentijd kun je voorbeelddata downloaden voor testen hier<\/A>, hier,<\/A> hier<\/A> en hier<\/A>. Dit zijn de initiële bulkversiekopie en enkele incrementele delta-bestanden met enkele dagen bewerkingen elk. Pas de pqPath-variabele in de notebook aan naar jouw omgeving totdat ik het S3-pad heb ingesteld.<\/P>Spoiler<\/A>De data die ik gebruik wordt eigenlijk niet onderhouden in een branch versioned geodatabase, ik heb voorbeelddata gemaakt; zie vriendelijk de datapermissies in de itemdetails van bovenstaande links.<\/DIV>
De data die ik gebruik wordt eigenlijk niet onderhouden in een branch versioned geodatabase, ik heb voorbeelddata gemaakt; zie vriendelijk de datapermissies in de itemdetails van bovenstaande links.<\/DIV><\/DIV>
In de notebook zie je dat ik een sjabloon lever voor extent- en tijdreisqueries. Ik kan alle 2,7 miljoen percelen in mijn data binnen iets meer dan 3 minuten extraheren vanaf lokale schijf. Toegang vanaf S3 verwacht ik iets langzamer, we zullen zien zodra ik dat heb ingesteld. Probeer zelf de notebook uit.<\/P>
Mogelijk heb je vragen over de notebook; ik probeer er alvast enkele te anticiperen:<\/P>
- DuckDB 1.0.0 wordt gebruikt omdat deze beschikbaar is in het Esri Conda-kanaal en latere versies geometrie anders behandelen<\/LI>
- De bbox-kolom in de parquet-bestanden is van JSON-type maar wordt bevraagd als varchar omdat DuckDB het niet als JSON leek te herkennen<\/LI>
- Ik probeerde gebruik te maken van de ingebouwde rowid pseudokolom in DuckDB maar kreeg fouten, dus heb ik deze overschreven<\/LI>
- Ik probeerde output feature classes te schrijven via een spatially enabled dataframe maar kreeg fouten<\/LI>
- In de blogdownload heeft het project atbx een scripttool die ik gebruikte om gewenste uitvoertekstveldbreedtes te vinden<\/LI><\/UL>
Nu ga ik even wat egoïstisch zijn. Om mijn voorbeelddata en parquet-bestanden te maken heb ik enkele ETL-tools gebouwd (Pro 3.4), die ik had kunnen scripten. Deze tools zitten niet in de blogdownload. Als je hierin geïnteresseerd bent, stuur me dan gerust een bericht zodat ik ze kan delen. Het helpt ons team hier als we horen hoeveel mensen geïnteresseerd zijn in dit datadelingparadigma, dus help ons alsjeblieft jou te helpen.<\/P>
